IRIX Base Documentation 1998 November/IRIX 6.5.2 Base Documentation November 1998.img/usr/relnotes/eoe/chC.z/chC

Text File | 1998-11-02 | 15KB | 397 lines

                                  - 1 -



       1.  _C_o_m_p_a_t_i_b_i_l_i_t_y

       This chapter contains information about compatibility issues
       within the IRIX6.x releases with respect to X/Open XPG4
       compliance and Posix compliance and also presents
       information regarding structural changes within the IRIX6.x
       releases that those developing kernel-loaded filesystem code
       need to be aware of.

       1.1  _X_P_G_4__c_o_m_p_a_t_i_b_i_l_i_t_y

       XPG4 compliance can be achieved by doing one of the
       following:

         1.  Installing the all platforms IRIX6.2 release along
             with the 6666....2222++++xxxxppppgggg4444 patch (patch 1125).

         2.  Installing the all platforms IRIX6.5 release.

       The default behavior for the IRIX6.2 and IRIX6.5 commands is
       non-X/Open XPG4 behavior which is traditional IRIX behavior.
       See the below discussion under ////ssssbbbbiiiinnnn////sssshhhh in order to obtain
       XPG4 behavior under the XPG4 compliant shell environment.

       1.1.1  _/_s_b_i_n_/_s_h  In order to obtain XPG4 behavior, the
       ////ssssbbbbiiiinnnn////sssshhhh shell must be used and the following environment
       variables must take on the below settings:

       eeeexxxxppppoooorrrrtttt ____XXXXPPPPGGGG====1111
       uuuunnnnsssseeeetttt NNNNOOOOMMMMSSSSGGGGLLLLAAAABBBBEEEELLLL
       eeeexxxxppppoooorrrrtttt NNNNOOOOMMMMSSSSGGGGSSSSEEEEVVVVEEEERRRRIIIITTTTYYYY====1111

       Please read the CCCCOOOOMMMMPPPPAAAATTTTIIIIBBBBIIIILLLLIIIITTTTYYYY IIIISSSSSSSSUUUUEEEESSSS section of the sssshhhh((((1111))))
       man page for further discussion.

       1.1.2  _/_s_b_i_n_/_s_e_d  There are several items which could
       produce compatibility inconsistencies between traditional
       IRIX behavior and X/Open XPG4 behavior.

       1.1.2.1  _s__a_n_d__l__c_o_m_m_a_n_d_s  See the man page sssseeeedddd((((1111)))).

       1.1.2.2  _e_s_c_a_p_e__c_h_a_r_a_c_t_e_r_s  Since X/Open regular expressions
       were introduced starting in IRIX6.4, there are some
       differences which can occur with respect to the back-slash
       escape character.

       The below example shows this incompatibility.















                                  - 2 -



       sed -n -e "/searchfor/,/\};/p" filename

       The file 'filename'  doesn't exist.

       Under IRIX6.2:
       ==============
       Can't open filename

       Under IRIX6.4 & 6.5
       ===================
       sed: command garbled: /searchfor/,/\};/p

       The problem lies with the \} sequence because '\{' and '\}' are
       meaningful to the X/Open regular expressions.  The sed script
       is in error by specifying '\}' and should just be '}'.  See the
       BBBBaaaassssiiiicccc RRRReeeegggguuuullllaaaarrrr EEEExxxxpppprrrreeeessssssssiiiioooonnnnssss section from rrrreeeeggggccccoooommmmpppp((((5555)))).

       1.1.3  _/_s_b_i_n_/_r_m  The ----iiii and the ----ffff options if both specified
       have a defined XPG4 behavior.  From the XPG4 specification:

            ----iiii ---- PPPPrrrroooommmmpppptttt ffffoooorrrr ccccoooonnnnffffiiiirrrrmmmmaaaattttiiiioooonnnn aaaassss ddddeeeessssccccrrrriiiibbbbeeeedddd pppprrrreeeevvvviiiioooouuuussssllllyyyy.... AAAAnnnnyyyy
            pppprrrreeeevvvviiiioooouuuussss ooooccccccccuuuurrrrrrrreeeennnncccceeeessss ooooffff tttthhhheeee ----ffff ooooppppttttiiiioooonnnn wwwwiiiillllllll bbbbeeee iiiiggggnnnnoooorrrreeeedddd....

       E.g., rrrrmmmm ----ffff ----iiii behaves differently than rrrrmmmm ----iiii ----ffff.  This is
       most of an issue with shell aliases or functions.

       1.1.4  _/_u_s_r_/_b_i_n_/_l_o_c_a_l_e_d_e_f  There is an incompatibility
       between generated versions of the LLLLCCCC____TTTTYYYYPPPPEEEE locale category
       prior to the IRIX 6.5 release and IRIX 6.5.  That is, binary
       locales generated prior to IRIX 6.5 will not be recognized
       by IRIX 6.5 and must be regenerated with the IRIX 6.5
       version of llllooooccccaaaalllleeeeddddeeeeffff((((1111)))).  See the NNNNOOOOTTTTEEEE section in the
       llllooooccccaaaalllleeeeddddeeeeffff((((1111)))) man page.

       1.1.5  _r_e_g_u_l_a_r__e_x_p_r_e_s_s_i_o_n_s  In IRIX6.3 and earlier the below
       IRIX 6.x versions of the commands:

       sssseeeedddd,,,, eeeedddd,,,, eeeexxxx,,,, eeeexxxxpppprrrr,,,, vvvviiii,,,, ggggrrrreeeepppp,,,, eeeeggggrrrreeeepppp,,,, fffflllleeeexxxx,,,, aaaawwwwkkkk,,,, ffffiiiinnnndddd,,,, ppppaaaaxxxx,,,, mmmmoooorrrreeee

       all used the rrrreeeeggggeeeexxxxpppp((((5555)))) version of regular expressions.  In
       IRIX6.4 and later versions of the above commands use the
       rrrreeeeggggccccoooommmmpppp((((5555)))) X/Open version of regular expressions.

       1.1.6  _k_e_r_n_e_l__s_y_s_t_u_n_e_s  The following systune variables must
       be set to be XPG4 compliant:

       ppppoooossssiiiixxxx____ttttttttyyyy____ddddeeeeffffaaaauuuulllltttt 1111
       rrrreeeessssttttrrrriiiicccctttteeeedddd____cccchhhhoooowwwwnnnn 1111














                                  - 3 -



       1.1.7  _c_o_m_p_i_l_a_t_i_o_n__e_n_v_i_r_o_n_m_e_n_t  The XPG4 compatible compiler
       is ////uuuussssrrrr////bbbbiiiinnnn////cccc88889999.  The following command line options must be
       passed to the ////uuuussssrrrr////bbbbiiiinnnn////cccc88889999 compiler:

       ----DDDD____XXXXOOOOPPPPEEEENNNN____SSSSOOOOUUUURRRRCCCCEEEE ----UUUUuuuunnnniiiixxxx

       1.1.8  _/_s_b_i_n_/_t_o_u_c_h  There is a Y2K incompatibility issue
       with the ttttoooouuuucccchhhh command in IRIX releases prior to IRIX 6.5.
       The Y2K compliant versions of the ttttoooouuuucccchhhh command exist in the
       IRIX 6.2+xpg4 patch as well as in the IRIX 6.5 release.  See
       the ttttoooouuuucccchhhh((((1111)))) man page for the ----tttt option usage.

       In particular, the behavior of the frequently used kernel
       driver exitop (to force kernels to be rebuilt after new
       drivers are installed) ttttoooouuuucccchhhh 0000111100001111000000000000000000000000 is now different,
       and its use will cause kernels to not be rebuilt when they
       should.  Instead use ttttoooouuuucccchhhh 111199997777000000001111000011110000000000000000.

       1.2  _P_o_s_i_x__c_o_m_p_a_t_i_b_i_l_i_t_y

       1.2.1  _k_e_r_n_e_l__s_y_s_t_u_n_e_s  The following systune variables must
       be set to be POSIX compliant:

       ppppoooossssiiiixxxx____ttttttttyyyy____ddddeeeeffffaaaauuuulllltttt 1111
       rrrreeeessssttttrrrriiiicccctttteeeedddd____cccchhhhoooowwwwnnnn 1111

       1.3  _F_i_l_e_s_y_s_t_e_m__i_m_p_l_e_m_e_n_t_a_t_i_o_n__i_s_s_u_e_s

       Significant changes have been made in IRIX6.x releases that
       those implementing and maintaining kernel-loaded filesystems
       need to be particularly aware of:

         1.  In IRIX6.4, a behavior stacking model was introduced
             which changes substantially the structure of VOP and
             VFS op signatures and requires other changes in
             filesystem code designed to be loaded with the kernel.

         2.  In IRIX6.5, the requirements for the use of the
             behavior stacking code have been tightened, requiring
             changes in addition to the normal modification of
             filesystem code to adapt to additions or signature
             changes in the VOP and VFS interfaces between IRIX6.4
             and IRIX6.5.

       1.3.1  _B_e_h_a_v_i_o_r__s_t_a_c_k_i_n_g__m_o_d_e_l__i_n__I_R_I_X_6_._4  IRIX6.4
       introduced new structures associated with v-objects such as
       vnodes and vfs's.  These allow multiple layers of filesystem
       implementation to be stacked such that one layer may
       interpose on calls (such as VOP's) for the v-object.  This
       structure has necessitated changes in external filesystem
       code, even when the filesystem in question does not











                                  - 4 -



       explicitly use any new features of this model.

       In IRIX6.4, the behavior head and behavior descriptor
       structures were introduced and the VOP and VFS interfaces
       were modified so that the initial parameter passed to the
       called ops functions was the behavior descriptor, rather
       then the v-object (vnode or vfs) itself.  In addition,
       filesystems needed to link a behavior descriptor onto the
       behavior chain and remove the behavior descriptor at object
       initialization and destruction time respectively.

       For filesystems using non-VSHARE vnodes,  (non-VSHARE vnode
       are those whose allocation is directly managed by the
       filesystem. VSHARE vnodes are managed in a global vnode pool
       shared by multiple filesystems), the filesystem needs to
       properly initialize the behavior head of the vnode
       immediately after it is allocated (using vn_bhv_head_init)
       and call a destroy function (vn_bhv_head_destroy) on the
       behavior head immediately before deallocating the vnode.

       If a filesystem implementation allocates its own vfs
       structures, similar requirements apply.  The behavior head
       within the vfs should be initialized using bhv_head_init and
       bhv_head_destroy should be called before deallocating the
       memory of the vfs structure.  This would be an unusual
       situation since typically the vfs is allocated by the kernel
       before calling the filesystem VFS_MOUNT routine and
       deallocated by the kernel after the filesystem's VFS_UNMOUNT
       routine has executed.

       See /usr/include/sys/vnode.h, /usr/include/sys/vfs.h, and
       /usr/include/ksys/behavior.h for a lot of relevant detail.

       1.3.2  _F_u_r_t_h_e_r__r_e_q_u_i_r_e_m_e_n_t_s__f_o_r__I_R_I_X_6_._5  For filesystem code
       developed to run in an IRIX6.4 kernel environment, the major
       change has to do with requirements to intialize and destroy
       behavior head structures in non-VSHARE vnode and in vfs
       structures allocated by the filesystem itself.

        While this was also part of the interface for IRIX6.4, as
       described above, the implementation allowed filesystem code
       to run successfully without dealing properly with the
       behavior head structures.  In particular, if the vnode (or
       an allocated vfs) was zeroed, the behavior head
       initialization did not need to be done and also, the destroy
       function was a no-op.  In IRIX6.5, this is no longer the
       case, the behavior head for a non-VSHARE vnode must be
       properly initialized and destroyed.

       Also note that it is more critical in IRIX6.5 that behaviors
       are properly unstacked before the objects associated with











                                  - 5 -



       them are made available for dellocation.  This may have gone
       unnnoticed in IRIX6.4.

       1.3.3  _S_u_m_m_a_r_y _o_f _r_e_q_u_i_r_e_m_e_n_t_s _f_o_r _b_e_h_a_v_i_o_r _s_t_r_u_c_t_u_r_e
       _m_a_n_a_g_e_m_e_n_t

       1.3.3.1  _F_o_r__n_o_n_-_V_S_H_A_R_E__v_n_o_d_e_s  A filesystem should, after
       using vn_alloc:

         1.  Initialize its behavior descriptor using
             vn_bhv_desc_init.

         2.  Link the behavior descriptor into the behavior head
             using vn_bhv_insert_initial.
       A filesystem should remove its behavior descriptor using
       vn_bhv_remove before returning from a VOP_RECLAIM or
       VOP_INACTIVE returning VN_INACTIVE_NOCACHE or before doing a
       direct vn_free.

       1.3.3.2  _F_o_r__n_o_n_-_V_S_H_A_R_E__v_n_o_d_e_s  A filesystem should, after
       allocating a vnode:

         1.  Initialize its behavior descriptor using
             vn_bhv_desc_init.

         2.  Initialize the behavior head of a new vnode using
             vn_bhv_head_init.

         3.  Link the behavior descriptor into the behavior head
             using vn_bhv_insert_initial.
       Before deallocating a vnode, a filesystem should:

         1.  Remove its behavior descriptor using vn_bhv_remove.

         2.  Call vn_bhv_head_destroy on the behavior head for the
             vnode to be deallocated.

       1.3.3.3  _F_o_r__n_o_r_m_a_l__(_i_._e__k_e_r_n_e_l_-_a_l_l_o_c_a_t_e_d_)__v_f_s__s_t_r_u_c_t_u_r_e_s
       At mount time, the filesystem should initialize its behavior
       descriptor and insert it in the vfs behavior head using
       vfs_insertbhv.

       At unmount time, the filesystem should remove its behavior
       descriptor from the vfs behavior head using VFS_REMOVEBHV.

       1.3.3.4  _F_o_r _v_f_s _s_t_r_u_c_t_u_r_e_s _a_l_l_o_c_a_t_e_d _b_y _t_h_e _f_i_l_e_s_y_s_t_e_m
       _i_t_s_e_l_f  After allocating such a vfs structure, the
       filesystem should:

         1.  Initialize the behavior head within the vfs, using
             bhv_head_init.











                                  - 6 -



         2.  Initialize its behavior descriptor and insert it in
             the vfs behavior head using vfs_insertbhv.
       Before deallocating such a vfs structure, the filesystem
       should:

         1.  Remove its behavior descriptor from the vfs behavior
             head using VFS_REMOVEBHV.

         2.  Use bhv_head_destroy on the behavior head for the vfs
             to get rid of any associated resources.